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Py ,MARKS 

Theindicationofallowablesubjectmatterwithrespect to claims 4-11 and22isapFeciated. 

A. Clafan 3 was rejected under 35 U.S.C. §102(b) as being anticipated by Rust et al (US 
6^23,134). The appUcant respectfully traverses this rejection for the foUowing reason(s). 

A class driver of Rust means a driver that can be used in common for groups of products of 
themeasuring equipment, such as an osciUosoopeandaDMM(digital multimeter). Tlie class driv^ 

of Rust does not comiect an application and a driver, as in the DIA (device independent access) 

hierarchy of the present invention. 

Claim 3 is directed towards a method for commonly controUing device drivers, 

comprising, in part, the step of: 

arranging a device independent access hierarchy between an application hierarchy and a 

device driver hierarchy. 

The Examiner states in the rejection (on page 2) "Rust teach« a method ffff co^^Qnly 
r/^ntmlling devir.^ Hrivers. ooi r fridug the atens of: arranging a dpvice indgPmdCTt higT^yphy 
hfttween an at?r"^^tion hierar rhv and a device driver hierarchy. And refers us to Fig. 5, (Class 
Drivers 304); and col. 1 3, lines 19-67. 

What Rust may or may not teach is subject matter to be considered under §103, not §102. 

Referring to Fig. 5 in Rust, Rust discloses, when a user application calls a predetermined 
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driver, calling me driver according toapointer with respecttolhepredetem 

present invention, as claimed, is directed to calling a driver using a common command for drivers. 

Under §102, there must be no difference between flie claimed invention and the reference 
disclosure, as viewed by a person of ordinary skill in the field of the invention, Scripps clinic & 
ResearchFoundationv, Genentech. Inc., 927F.2d 1565, 18USPQ2d 1001, 18USPQ2d 1896 (Fed. 
Cir. 1991). 

Note that in order for an anticipation rejection to be proper, the anticipating reference must 
disclose exactly what is clahned. "A claim is anticipated only if each and every element as set forth 
in the claim is found, either expressly or inherently described, in a single prior art reference." 
Venlegaal Bros. v. Union Oil Co. of California . 2 USPQ2d 1051, 1053 (Fed. Cir. 1987). "The 
identical invention must be shown in as complete detail as is contained in the ... c\wm.michardson 
v.5uzufo AfotorCo..9USPQ2dl913,1920(Fed. Cir. 1989). Note here that the Examiner has not 
reUed on "inherency," accordingly, each and every element must be expressly described in Rust. 

The underlinedportionoftheExaminer'sstatementofrejectionaboveis language notfound 

in Rust, and is in fact the same langut^e used in the Applicant's claim. 

A review of Rust finds no use of the term "device independent access." 
Accordingly, the rejection is not clear. 

Although the Examiner refers us to Fig. 5, (Class Drivers 304); and col. 13, lines 19-67, we 
cannot determine whidi of Rust's elements correspond to the term "device independent access" or 
"device independent access hierarchy." 

The Examiner is referred to 37 CFR §1.104(c)(2) which directs the Examiner to designate 
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the particular part rdied on .P.rW practicable, when a reference is complex . The pertinence 
of each reference, if not apparent, must be clearly explained. 

CitingFig. 5, (Class Drivers 304); and col. 13,lines 19-67 is clearlynot as nearly practicable 
enough since the tenn ''hierarchy" is not used in Rust, and since the term ""device independent 

access" is not used in Rust. 

Additionally, claim 3 is directed towards a method for commonly controlling device drivers, 

comprising, in part, the step of; 

definingftmctiomavaiUAleinacorrespondingdeviceMver 

block in a Junction table. 

According to the present spedfication, paragraph [0034]: "In 

invention, only functions available in a corresponding device driver among functions of a fanction 
block defined and standardized in international organizations such as rrU/RFC (International 
TeleconimunicationsUmon/RequestForConmieots), eto is defined inafu^^ 
invention employs all function blocks defined in standardized documents made by international 
organizations for standardization such as ITU (Ihtemational Telecommunications Union). lETE 
(tatemetEngineeringTaskForce),ETSI(EuiopeanTelecommunicationsStandardizationInsti^^^^^ 
ATM(AsynchronousTramferMode)forum,ADSL(AsymmetricaimgitalSubscriberline)forum, 
cto. In the embodiment of Ihepiesent invention, onlyfmctionsavailablein the conespondingdeviM 

driver among functions of all function blocks defined by the international organizations for 
standardization are re-defined in the function table." 

The Examiner refers us to Rust's col. 6. lines 34-51, IVI engine 306, col. 16, lines 28-49, 
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"...anay of function names...", and col. 23, lines 29-42. 

Rust's IVI (interchangeable virtual instrument) engine 306 communicates with each of the 
class drivers 304, the generic capabilities portion of the specific driver 308 and the 
instrument-specific capabiUties portion of the specific driver 308 . The IVI engine also couples to the 
imtializationfile^efeIredtoasIVI.I^^3lO. As shown. themengine306andthespecific^^^ 

include bidirectional communication. The IVI engine 306 operates to create and manipulate IVI 
instrument driver objects. The IVI engine 306 also manages fimction pointers to the specific driver 
and caUsdriver-spedfic attribute callback. ThelVIengine 306 furthermanagesalli^ 
attributes and performs Set and Get attribute operations. The IVI engine 306 also performs state 
cadiing and attribute simulation operations. 

When the user application 302 makes acall orinvokes a method on the class driver 304, the 
class driver 304 accesses information in the IVI Engine 306. The class driver 304 uses services 
provided by the IVI engine 306 to access the respective fimction in the specific instrument drivers 
308 which performs the operation on the specific instrument. More specifically, when the class 
driver receivesafimction call, the IVI engine 306 providesapointer to the class driver, wherein 1^^ 

pointer points to the respective fimction in the specific driver. In other words, all calls to the class 
driver 304 actually invoke the specific instrument drivers 308 of the instrument being called. Thus 
the class driver 304 itself does not actually configure or "touch" the instrument, but rather preferably 
in every case the specific instrument drivers 308 of the instrument is invoked to actuaUy perform the 
configuration or operation. The IVI engine 306 thus operates with a respective class driver 304 to 
enable operation of the class driver 304 within the system. The IVI engine 306 is capable of 
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operating with each of the class drivers 304 within the system. Thus the IVI engine 306 is generic 
to each of the class drivers 304 and provides services to each of the class drivers 304. 

The specific drivers 308 is operable to use services and/or functions in the IVI engine 306, 
such as set attribute and get attribute functions in the IVI engine 306. Likewise, the IVI engine 306 
isopei^letoinvokecallbacks in thespedficdriver308 to performits services and/or fto^ 
IVI engine 306 preferably includes a plurality of set attribute and get attribute functions, each for a 
respective data type. For example, the IVI engine 306 preferably includes set attribute and get 
attribute functions for data types such as int32, real 64, Booleans, strings, pointers, etc. 

Therefore, the functions, such as the set and get function, of IVI engine 306 are noX functions 

J 

available in a corresponding device driver, but instead are only fiinctions of IVI engine 306. 

Additionally, there is no junction table disclosed, and there are no Junctions of a Junction 
block in a Junction table disclosed in Rust, especially with respect to IVI engine 306. 

In the columns cited by the Examiner, Col. 23, line36 mentions a table examined by the IVI 
engine 306, and this table is located in IVLini (a configuration or initialization file) file 310 of Fig. 
5. 

Rust discloseslhat theinitializationor configuration file (INI file) 3 10 comprises information 
on each of theinshimients or virtiial instrum«its present in the instrumentation system. The INI file 
310 maps Logical Names used in a program to a Virtual Instrument section. The Virtual Instrument 
Section operates to link a hardware section and a driver section. The Virtual Instrument Section also 
sets driver modes, such as range checking, simulation, spying, interchangeability checking, and 
instrument statijs checking, using parameters caUed rangeCheck, simulate, spy, interchangeCheck, 
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and querymstrStatus. The INI file also defines Virtual Channel Names which map channel name 
aUases to instrument-specific channel names and specifies a default instrument setup for the virtual 
instrument 

For example, if the user application generically references a DMM (digital multimeter) as 
'•D^IMl^theconfigu^ationfilestaresin&^nationreg9rdingwhich actual ins^ 
driver in the system corresponds to D^ml . The configuration file stores information reg^^^ 

address of the instrument and the location of the instrument driver. This enables the system to load 
the specific driver and communicate with the instrument. 

As an example of the initialization operation, the user appUcation calls the init fimction in 
step422 with the logical name "DMMi^^lle class driver 3(H receives thelogicalnameins^ 

and directs the IVI engine 306 to open up DMMl in step 426. Tlie class driver 304 also provides an 
array of fimction names in step 426 that it expects the instrument driver 308 to have. The IVI engine 
306 examines the table in the IVI.im file in step 428. determines the location of DMMl , and loads 
the instrumrat driver for DMMl in step 430. 

The table in the IVI-ini file 310 is not disclosed as being a fimction table, and there is no 
mention of fi*nctions of a fimction block in a fimction table anywhere in Rust 

*y.. fin»l f«iertinn fBaf<ilv j^^tnits on na e ^ 1 ft line 20 that Rust doe^ not expli<?itlY describe 

a table. 

Tl^ ^. F , y;.miTier then BO? f» nn to state Rust discloses dejjned fiinfft-ions provided in fcg sp^fic 
lirivers that ar«r>^11ab1ebvns ( ^f .n^ ti'«tinns.rf^erringto col. 6, Mngs 19-5^ mdcol H. lmes4S-gg 
«r.A that the snf^fi^ H^r^ driv e r """^^ ^>"'' ^ ^'"""e ^06 to ObtajTI a MctiOR 
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^ fh. .n^ific d '-^'i^- .iriv^ ^n«- tf f'^^ P '^'^ 4. lines S?,-54 and col 2] . lif es 24-30. 

.pen from the cttods<^onsgfRvst e^phoft^)pspecifip instrument 
Hriv^ are cppcific to an inj - tnimpnt of a certain class. Tn^Mafa^tlnw , mod<^1 and to^W^e 
fvn.. Tt ^ ii ff i?i^.^t>. .v^tem still miiiires spgcifir driv<^ ^0^ for each jpsfrutnegt. 

.r^ >»tnred therdn , r^na. not n ^^^n th.t these fimrHon «re dgfiflfd fis frucHofis flVMlal^le ffi a 
r^nanHing dcfuir^ driver flmo H f ^'^'•ti^"^ l^'nrtion block in Q function tqble . 

c„y||, ^n,v.t1,^factthatt ^ « T'^fir-aevice5(1rivmhav6t0benrrfflfi<^inor^^ 
fimrrrinn of a soe^fi^ ^^vi^^ clearl y ^nHi..t«. that Rust's culling fijnctiotl is (^e^ri^^. Hepcndgnt. ffQt 
Heviee indeneiiH^^t Thus Rust to Hisclose armnrim a device iV(fppfn<i'^t " W Mmrchv 
h.t^..n an annhr-^n. hi.rnrrhv ^ g' f fT/^-^^^^^ ^"^^^ ft»mrrftv as hV t^ff filT^t feftlM^ Pf 

claim 3. 

T<rn^ ^ in Fip S of Rust th f>t is no el >^«mt such as a device ind^imdentqr^mf hjerqrthy 
hBtwee p ^liV^tion 30? and class driv^ 304 ^ddiripnally TYT Hnpigg 306 is 
Hi ^^ hBtwer .U.. Hr,v..rs 30 4 .nH «^ific driver 308. not between the mi \ S^9n 30^ aqd 
pther the cla«is arivers 304 the specific drivers 308- 

«fr^ifin«l1v Rmt c iicnln««^ in eol. 6. lines 22+. that the user anplipation ffreferably 
m«kes calls tn the class driv e r All the fanctions in the claSS dliVCT m mf^^ fimfftigflS. i.ft. 
fiinerimif. which 5»« common t o «11 CM- mostofthesneaficdrivetSWithm the daS^^ 
instrument iptpmhangeahilitv y^^f^i^ of the nresent inveation Thwi tbeffi >^ Clg^rW tt l CTe iS ftP 
element sucH as a /fevicg ind '^ p^ndent acce s '> his>rariihv disnosed between iiser application 30? and 
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y.^ass driver 104, as evid ftnced hv Fig. 5. 

Accordingly, the rejection of claim 3 is deemed to be in error and should be withdrawn. 

Claim 3 is directed towards a method for commonly controlling device drivers, 

comprising, in part, the step of: 

when a device is initialized, allowing said device ind^ndent access hierarchy to generate 

adevicehandleridentyierimsedrmbaxiag.asta^ 

transmitthegenerateddevicehandlerUientifier h<iyinthfnt(^ 

application hierarchy of a higher order. 

HeretJieExaminerrefasto severalinstances whereintheterai "handle" appears in Rust, such 

as col. 20, lines 35-46; col 23, lines 12-21 ; and col. 24, lines 22-29. 

The foregoing feature of daim 3 requires said device independent access hierarchy to 
generate a device handler identifier. In col. 20. lines 35-46. Rust discloses "the user appUcation 
includes calls to a driver initialization function (init) in the class driver 304 which creates or 
instantiates the driver and returns a handle." There is no device independent access hierarchy 
disclosed in Rust, and it is ttie class driver 304 which returns a handle. 

The cited section col 23, lines 12-21 discusses step 426 in Rust and state: "After step 462 the 
initialization function call originaUy made by the user application has been completely executed. 
From this point on, whenever the iw«r application ^07 calls a fanction in the dass driver, fljs 
fiiticrinn call includes the handle th «t is relumed fiom the init fimction (as discussed above with 
respect to col. 20, lines 35-46) to specify whidi instrument is being communicated with." See step 
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462 in Fig. 7D. 

The cited section col. 24, lines 22-29 of Rust summarizes the forgoing. 

Additionally, of the above mentioned cited sections of Rust, there is no disclosed device 
handler identifier generated in Rust having a standardized common data format. As can be seen 
fimn the Examiner's rejection, the Examiner appears to only be interested in Rust's disclosure of a 
handle, as there is no mention in the rejection of where Rust is supposed to disclose generation of 
a device handler identifier having a standardized common data format. 

T» i Ti. fin.i reiecrion. pa p^ in lines 10- the Examiner staffs m "teacher the^ 
|i«.i..tin»«" Res j^^^ th. feet that fails to teftob the forepoiup feature, of claim 3„ as noted 

Accordingly, the rejection of daim 3 is deemed to be in error and should be withdrawn. 

Claim 3 is directed towards a method for commonly controlling device drivers, 

comprising, in part, the step of: 

allowing the higher-order application hierarchy to call a predetermined device using the 
device handler '^^^f-- hmv? ^t^rdized common data form<it, and allowing said device 
independent access hierarchy to identify afimcHon of the corresponding device driver from the 
fimction table using the device handler identifier f{(fvinrfh(fmndardized rommn rfffft? format arid 
call the Junction of the corresponding device driver. 

As noted previously, there is no disclosed device independent access hierarchy and there is 
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no disclosed function table in Rust. 

Referring to Fig. 5 in Rust, Rust discloses, when a user application calls a predetermined 
driver, callingthedriveraccoidingtoapointerwithrespecttothepredetern^ 
present invention, as claimed, is directed to calling a driver using a common command for drivers. 

Therefore, Rust does not disclose a method of calling a driver using the common command, 
but discloses calling the corresponding driver according to an identifier of each driver, Further,Rust 
teaches that appUcation A and appUcation B respectively call a driver A and driver B using each 
identifier. In the present invention, application A and application B respectively caU driver A and 

driver B through one command. 

Accordingly, the rejection of claim 3 is deemed to be in error and should be withdrawn. 

B. Claims 1, 2 and 12-21 were rejected under 35 U.S.C. §103(a), as rendered obvious and 
unpatentable, over Rust et aL in view of Pike et al. (US 6,993,772). The AppUcant respectfully 
traverses this rejection for the following reason(s>. 

Claim 1 is directed towards a method fiw commonly controlling device drivers, 

comprising, in part, a step of: 

arranging a device independent access hierarchy between an application hierarchy and a 
device driver hierarchy and applying a standardized rule of said device ind^ndent access 
hierarchy to said application hierarchy and said device driver hierarchy. 
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As discussed above, Rust failsto discuss a device independent access hierarchy andlookiiig 
to Fig. 5 in Rust, there is no element such as a device independent access hierarchy disposed 
between user application 302 and class driver 304. 

Additionally, Rust fails to discuss a standardized rule. 

Accordingly, the rejection of claim 1 is deemed to be in error and should be withdrawn. 

Claim 1 is directed towards a method for commonly controlling device drivers, 

comprising, in part, a step of. 

allowing said application hierarchy and said device driver hierarchy to access the device 
driver hierarchy and said application hierarchy through the standardized rule of said device 
independent access hierarchy, respectively. 

The Examiner notes that Rust fails to teach the foregoing feature and refers to Pike's 
Instrument Engine 102 and Col. 8, lines 3-14. Hie Examiner then statesit would have been obvious 
to one of ordinary skilllhe art at the time of the invention was made to combine the teaching of Pike 
and Rust because the teaching of Pike "would improve the system of Rust by allowing 
communicationbetweenauser application and device driver such thataresponse could be reh^ 

to the user tqiplicadon." 

The Examinerhasnot identified what such a "response" wouldbenor why it wouldbe of use 

to Rust. 

The Examiner has not identified any problem with Rust' s system and method for controlling 
an instrumentation system such that one of ordinary skill the art at the time of the invention was 
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made would have desired to look to the related art for a solution to such a system. 

The Examiner has not identified how a "response" (noting that we have no idea what the 
response is supposed be) would improve the system of Rust by allowing commumcation between 
a user plication and device driver such that a response could be returned to the user appKcation. 
smce communication between a user appKcation and device driver is already allowed sudi that a 
handle is already returned from class drivers 304 to user application 302 as disclosed in Rust's col. 
20, lines 38-41. 

Thus, wifhoutafectualbasistosupportthebasisofobviousness,itappears that the Examiner 
merely speculates that the combination of Pike and Rust would improve the system of Rust. 

Deficiencies in tiie fectual basis cannot be supplied by resorting to speculation or 
unsupported generalities. In re Warner, 379 F.2d 1011, 154 USPQ 173 (CCPA 1967) and In re 
Freed, 425 F.2d 785, 165 USPQ 570 (CCPA 1970). 

Accordingly, the Examiner fails to establish aprimafade bases of obviousness. 

In re Rifckaert, 28 USPQ2d 1955 (CAFC 1 993) states: 

"A prima facie case of obviousness is established when tiie teachings 
from the prior art itself would appear to have suggested the claimed 
subject matter to a person of ordinary skiU in the ait" In re Bell, 991 
F 2d 781, 782, 26 USPQ2d 1529, 1531 (Fed. Cir. 1993) (quoting In 
re Rhinekart. 531 F.2d 1048, 1051, 189 USPQ 143, 147 (CCPA 
1976). If flie examiner fails to establish a prima facie case, the 
rejection is improper and will be overturned. Inre Fine,S31 FJ.d 
1071, 1074, 5 USPQ2d 1596, 1598 (Fed. Cir. 1988). 

Additionally, Pike feils to teach or discuss the features of claim 1 noted above as lacking in 
Rust, such as, a device independent access hierarchy and a standardized rule. 
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Accordingly, the rejection of claim 1 is deemed to be in error and should be withdrawn. 
Claim 2 is deemed to be non-obvious for the same reasons as discussed above. 

thpfiti ^l reiecrionther^i«nn argume n t prnvidedbv the RxaminertO disfwit^ the forggoipg 
♦r^v^«lnfthet^^i»T, T«stead.t h ?i^^»tr.inerremarVsthatthetestforobvinilsny!^>»if^"fftWh^^^^ 
th. fP.h,rB. of a s ^ nnH^rv reference mav be bodilv incorppnited \m tH? m^^' Pri^narv 
reference: nor i» it that the clai m ^^r^ invention must be expressly suBgestgd w a^y ong <?r all ojM 
rrf»r^r«. Rather thp t«,t is what comhined teaching of the refcrenrp^ ti«Yg sVlfigg8tg4 

to those of ordinary s kill in the art. 

I^ntft here that the Afp1ifi»nt has m a rie no argument concerning wheth^ ftr m featVffgs qf 
Pik« could he boHilvincomorate H into the structure of Rust, nor that Hie clftim^ mv^tiQIl m^$t bg 
«vpr«.slv sugg«^*^ in anv one o r M of the references, since that WHf? not the basis pf ftg rejectiQn, 
tv,« Annlicanth ^« ««r. f»i«ri that there has been no pnmff shoyrmg t^^al tfaei? is ^ 
proM^m, with t h «. oommimication ^ytwppn the device driver and user applirflti on and tllgre has t.gen 
prima iacie showing that th « -» t^»»cMng of Pike "would immOVe thg f^tm fff B^^St aHOWing 
«>nininnicatiotih«tween auser ^Hr-^tmn and dervice driver SUcb thflt^lT^SPQaSff COuldb^KtMned 
to the ii,.er ai ^ j fr^tion " Note t ^^^ Rnst aWv allows for commuuication betw^ a qser 
a pplication aP^ dRvice drive r «nio>i that a response could be renJIUftl tp the \m greliCfltiWl. 



Accordingly, the rejection is deemed to be in error, and should be withdrawn. 
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i Claim 12 is directed towards a method, comprising, in part, a step of: 
requesting loss of signed state informationlyase^ksy^ 
by an application to a device independent access hierarchy. 

Looking to both Rust and Pike we find no mention of concern with respect to loss of signal 

state information. 

-Die Examiner refers to Rust's teadiing of "check instrument status". However, "check 
instrument status" is deemed not to correspond to loss of signal state information. 

AdditionaUy, it is required that the appUcation make the request to the device independent 
access hierarchy. See Applicant's paraff^ph [0032]. 

hi Rust the "check instrument status" resides in the specific driver 308. 

fa rt,« finRi reiectjnn 11 . line s n-1 7, the Examiner refers us to Rlisf . 2$, Mr j ss 24- 
and col. 3fi lines 46-49. T^nth nf these s ^rHmis clearlv disclose that the error cnectmg is a, 
fi«i«Hon of thP driver. There 1 9 yf^ rfi^^nsnre in these cited sections of Rust to I pdjcatg X\ia^ the er^Qi: 
checking is feqii^t«1 hv an b li^Hon nor that there is a rMUeSt m^Af' tp <imVi mdepm^gtf 

Accordingly, the rejection of daim 12 is deemed to be in error and should be withdrawn. 

Claim 1 2 is directed towards a method, comprising, in part, a step of: 
converting the request from said application into a first device local format and requesting 
a first device driver to provide the loss of signal state information to said device independent access 
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hierarchy. 

Here the Examiner refers to Rust'scol. 15, lines 24-45, and specificaUy to lines 26-29, U.. 
"In olher words, when creating a user appUcation 302. the user is generally only required to have 
knowledge of the class driver 304 . . ." 

It is not clear why the Examiner refers to the above cited section of Rust, as there is nothing 
in col. 15, lines 24-45 deahngwiththeprevious cited portion of Rustregarding'-checkinstniment 

status". 

Similarly, the Examiner refers to Rust's Fig. 8A and col. 24, lines 43-45 which have no 
connection to Rust regarding "dieck instrument status". 

It appears the Exammer is merely picking and choosing certain parts of Rust in an attempt 

to deprecate the claims. 

It is impermissible within the framework of section 103 to pick and choose from any one 
reference only so mu<*ofit as wiUsupportagivenposition to the exclusion of other parts necessary 

to the fiiU appreciation of what such reference fairly suggests to one skilled in the art 

In re WessUm, 353 F.2d 238, 241, 147 USPQ 391, 393 (CCPA 1965); see also In re Mercer, 515 

F.2d 1161, 1165-66, 185 USPQ 774, 778 (CCPA 1975). 

One cannot use hindsight reconstruction to pidc and choose among isolated disclosures in 
the prior art to deprecate the claimed mvention. In re Fine, 837 F.2d at 1075. 5 USPQ2d at 1600. 

Pike was not rehed on with respect to the foregoing features of claim 12. 

Accordingly, the rejection of claim 12 is deemed to be in eiror and should be withdrawn. 
The remaining features of claim 12 and claims 13-21 will not be addressed herein, as it should be 
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ite clear that the combined teachings of Rust and Pike do not support the rejection. 



quite 



Theexanunerisrespectfullyrequestedtoreconsidertheapplication, withdraw 
and/orr«dectionsandpass the application toissufi in viewof the aboveamendmeatsm^^^^ 

Should a Petition for extension of time be required with the ffling of this Response, the 
Commissioner is kindly requested to treat this paragraph as such a request and is authorized to 
charge Deposit Account No. 02-4943 of AppUcant's undersigned attorney in the amount of the 
incuned fee if, and only if. a petition for extension of time be required and a check of the requisite 
amount is not enclosed* 

RespectfiiUy^submitted, 



Robert E. Bushneil 
Attorney for Applicant 
Reg. No.: 27,774 



1522 K Street, N.W. 
Washington, D.C. 20005 
(202) 408-9040 

Folio: P56833 
Date: 8/1/07 
LD.: REB/MDP 
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